The Seven Phases of AI-Assisted Development

As you work with an AI coding assistant—in this case, Claude Code—there are seven specific phases of development you should follow to ship high-quality work. While the specific implementation might vary depending on whether you are using Ralph loops, GSD, or SpecKit, these phases represent a common foundation for successful AI engineering.

Engineering fundamentals remain critical even in the age of artificial intelligence. Building applications that are built to last requires moving beyond "vibe coding" and adopting a serious, structured approach to development. These seven phases provide that structure, ensuring that your projects are robust and well-executed.

Phase One: The Idea

[0:00:57] Every project begins with an idea, which serves as the primary reason for invoking the development process. This idea can range in scale from a complete application concept to a narrow task within an existing codebase. It encompasses new features, specific bug fixes, and even code refactors. Whether the idea is massive or tiny and focused, the process remains the same.

The primary goal of this phase is to eventually translate the idea into a set of tickets or a task list. These tasks might be handled by multiple AI agents working simultaneously or by a single agent completing them sequentially. Regardless of the complexity, the idea is the catalyst that sets the entire workflow in motion.

Phase Two: The Research Phase

[0:01:52] If your idea involves difficult exploration or unfamiliar territory, you should include a dedicated research phase. This is particularly important when you are working with external APIs that are not widely known, such as a complex Stripe integration. Because AI agents often explore a repository in a fresh context window, difficult-to-access information can hinder their progress.

To solve this, you should create a research asset, such as a research.md file, to cache the findings. By documenting the research and placing it inside the repository or somewhere accessible to the agent, you provide a stable knowledge base. This prevents the agent from having to repeatedly struggle with the same external documentation or difficult-to-reach data.

Phase Three: Prototyping

[0:02:41] Prototyping is the stage where you begin to visualize what you are building, even if the exact "why" or "how" isn't fully solidified. This phase is essential for imposing your own personal taste on the outcome. For example, if you need a user interface to look or behave in a specific way, you may not know which direction to take until you see several options.

A successful strategy is to have the Large Language Model (LLM) generate multiple versions of an idea on a throwaway route. This allows you to see different ways the AI thinks the project could be built. By iterating on these versions over a few sessions, you can identify the best approach early. Once you settle on a direction, you can commit that prototype to the codebase, making it available for the agent to use as a reference during the actual implementation.

Phase Four: Creating the Product Requirements Document

[0:03:25] Once you have completed the research and seen initial code through prototyping, it is time to properly describe the destination. This is the PRD (Product Requirements Document) phase. At this point, you should feel confident enough to define the end state of the project—the final result you are trying to create.

While you may not yet know every single implementation decision, you should understand the basic experience the user will have and how the application will behave. The PRD acts as a document that describes the end state of where the project is going, ensuring that both you and the AI agent are aligned on the ultimate goal.

Hammering Out the Design

We are going toward a defined end state, and in the process of creating this, we really need to hammer out the design. This means we must prompt the agent to absolutely grill us, walking down every part of our decision tree. I have a writer PRD skill that is purpose-designed for this specific task.

Translating the PRD into an Implementation Plan

Once we have created the PRD, it is time to start breaking it down into an implementation plan. For those who are not developers or have never used a Kanban board or a Jira board, a Kanban board is simply a list of tickets that have blocking relationships between them. We are essentially describing the work that needs to be done.

I use a separate skill for turning the PRD into separate issues. While we could create a single sequential plan to turn the PRD into actual code, a Kanban board allows us to parallelize the work effectively. I can find all the tickets on my board that are not currently blocked and spin up an agent for each one to resolve them.

Executing the Work with Coding Agents

The next phase is execution. This involves running a coding agent in a loop to execute all the tickets on the Kanban board. In most cases, you will not actually need to parallelize this; a sequential agent working through each ticket is usually enough. For my workflow, this is a Ralph loop, which works very effectively with this setup.

The Quality Assurance and Iteration Loop

Finally, once execution is complete and you have a finished asset to look at, you get the agent to create a QA plan for the human to test the completed work. This step usually results in more tasks being added back to the Kanban board, requiring another trip through the execution loop.

You will tend to loop these last three steps—implementation planning, execution, and QA—quite a few times as you iterate toward a perfect product. In this context, QA also involves a human reading the code produced during the execution loop. This might not always be necessary, particularly if you are using a gray box architecture, but it is a valuable part of the process.

Reviewing the Seven-Phase Workflow

These seven phases represent the framework I use whenever I am working with an AI agent. We start with the idea, which could be an app, a feature, or a refactor. If there are external dependencies or difficult explore phases, we cache that knowledge in a research phase.

It is important to note that this research generally only lives for the lifetime of the specific sprint or the idea we are imposing on the application. Research can go out of date or rot away, which might cause an agent to take a wrong turn later if it relies on stale information.

Prototyping and Specification

If I need to impose my personal taste, I use a prototype. I will sit with an agent in a human-in-the-loop setup to hash out ideas. This is not strictly for design; it can also be used for software architecture or testing an external service. This is an essential step because the PRD can be a bit too abstract; you need concrete feedback first.

Next, I write the PRD, which serves as the documentation and the specification for our destination. I then turn that PRD into a Kanban board to understand the journey. I generally use GitHub issues for both the PRD and the Kanban board because it is convenient, although GitHub does not yet have a built-in way to represent blocking relationships between tickets. You might be better off using a tool like Linear, which does support those relationships.

AFK Execution and Human QA

Once the Kanban board is ready, I execute it in a loop, specifically a Ralph loop. While you could perform execution in a human-in-the-loop style by sitting and executing tickets individually, I find that with the right research, prototype, and Kanban setup, you can run the execution loop AFK (away from keyboard) and still achieve high-quality results.

To ensure those results are solid, we enter the QA phase. The agent produces a QA plan, and then a human actually walks through and tests the completed work. This produces more tickets for the Kanban board, leading to more execution and more QA. These phases will likely grow to eight or nine as I develop more ideas, as there is currently no explicit mention of code review in this seven-phase breakdown.

Integrating Code Review

[0:08:08] While it is not explicitly listed as a separate stage in the current workflow, code review is a vital component of the development process. It could potentially be incorporated as part of the execution flow or managed within the QA phase. In any case, performing code reviews is an essential step for anyone dedicated to producing good code.

Conclusion and Resources

The structured approach described reflects a deep commitment to maintaining high standards in software development. If you also prioritize the creation of good code, you are encouraged to check out the newsletter for more detailed discussions and updates. [0:08:24] Thank you for watching, and I look forward to seeing you again very soon.